1. Field of Invention
This invention relates to a verification support system which executes a variety of verifications on a general purpose engineering work station (hereinafter called "EWS"); and more particularly, to such system which executes verification of hardware and software of a CPU (central processing unit) mounted circuit on the general purpose EWS, or executes verification of a sequence program that a programmable logic controller (hereinafter called "PLC") executes on the general purpose EWS.
2. Description of the Prior Art
Before discussing the various categories of conventional verification support systems and problems encountered thereby, a verification support system for performing verification of the hardware and software of a CPU mounted circuit will be described. The target of verification is a printed circuit board or application specific integrated circuit (hereinafter called "ASIC") on which a ROM, a RAM, and a user logic are mounted around a general purpose CPU. The printed circuit board and ASIC are generally referred to as a CPU mounted circuit. The verification support system executes the verification of the hardware and software of the CUP mounted circuit on the general purpose EWS. The foregoing and other conventional verification support systems may be divided into six categories (a)-(f), which are discussed below.
Category (a) Prior Art System and Problems
In circuit emulators (hereinafter called "ICE") are extensively used to enhance the efficiency of development of computers. The ICE is mounted in a computer development support system and functions as the CPU of a computer, which is the subject of development, and executes verification of the hardware and software of the subject computer.
FIG. 1 depicts a CPU mounted circuit 1 which is the target or subject of the development and comprises a general purpose CPU 2, which is the core of the CPU mounted circuit 1; a ROM 3 for program storage; a RAM 4 for data storage; and a user logic 5 which is a circuit part that the user builds. User logic 5 is a signal processing circuit including an A/D converter, and the like, for example, which can access general purpose CPU 2 for reading and writing of data.
Verification of the hardware and software of a CPU mounted circuit 1 has so far been performed with an ICE 6 related to the general purpose CPU 2, after the CPU has actually been made.
The development of ASICs with a CPU core mounted therein has been extensively carried out for the purpose of high scale integration and miniaturization of equipments or systems.
FIG. 2 depicts the prior art environment under which the development and debugging of an ASIC are performed, wherein a CAD (computer aided design) 7 for designing a user circuit and a CAD 8 for designing a CPU mounted circuit are provided. A personal computer 9 is provided in a computer development support system and an ICE 10 is operated under control of personal computer 9. A C source (i.e. source program of C language) is converted by a C compiler (i.e. compiler of C language) into object codes, which are inputted to personal computer 9. A CPU mounted circuit 11 is provided for evaluation. A user circuit 12, only a portion of which is ASICed is provided.
As shown in FIG. 2, even when the entire board is finally ASICed, the CPU mounted circuit 11, in which only the user circuit part 12 was ASICed, is first made, and then, this CPU mounted circuit 11 is verified with the ICE 10 in the same way as described above.
However, in the conventional examples in which verification is performed after the CPU mounted circuit has actually been made, or after the CPUmounted circuit for evaluation, having only the user circuit part ASICed, has actually been made, as described above, there exist the following problems:
(1) Since the actually made CPU mounted circuit is verified by a worker applying a probe thereinto, when the operation of the CPU is made to be of high speed, it is difficult to verify at the actual operational speed.
(2) When the circuits on the board are of high-scale integration, it becomes difficult to physically apply a probe to the wiring patterns.
(3) When, as a result of verification, abnormality is found in the hardware of the CPU mounted circuit, the CPU mounted circuit must be remade. This results in an additional development cost and increases the development time. More particularly, when the abnormality is found in the ASICed user circuit, this becomes a large problem.
Category (b) Prior Art System and Problems
Recently, as general purpose EWSs and logic simulators have become more cost effective and have increased in operational speed, verification of the hardware and software of CPU mounted circuits has been performed by logic simulation.
When verification of the circuit of FIG. 1 is performed with logic simulation, a virtual model of a CPU mounted circuit, such as shown in FIG. 3, is made. FIG. 3 depicts a CPU mounted circuit model 21 comprising a general purpose CPU model 22, a ROM model 23, a RAM model 24 and a user logic model 25. These are virtual models of the corresponding components, and can be realized with use of appropriate software.
A source file described in C language, for example, is compiled with a C compiler, and the object codes, comprising 0 and 1 patterns generated as a result, are loaded down into ROM model 23 when logic simulation is started. The loaded program is executed by the general purpose CPU model 22 once verification of the software is performed. The source file is an application program made by the user, and the C compiler is provided by the user. How efficiently the above-described logic simulation can be performed greatly influences the shortening of the time it takes to develope the CPU mounted circuit.
FIG. 4 shows the steps of a program stored in ROM model 23, wherein the program comprises a related sequence of Steps 1 to N (wherein N represents an integer). The related sequence of steps 1 to N is intended to mean that Step 2 is performed with data obtained in Step 1, Step 3 is performed with data obtained in Step 2, and thereafter, subsequent Steps are likewise related to each other in the same manner.
FIG. 5 shows the Steps of verifying the program of FIG. 4 stored in ROM model 23. The flow chart of FIG. 5 shows that no errors were found in the verification. The Steps of verification described below as Steps (A1) through (A5) correspond to Steps A1 through A5 of FIG. 5.
(A1) Start the logic simulator to start logic simulation.
(A2) The object codes of a program for performing verification are loaded down into ROM model 23.
(A3) General purpose CPU model 22 is started, and the object codes are read out in sequence by ROM model 23, and instructions are executed.
(A4) The program of Steps 1 to N, through Step M, is executed in sequence and verification is performed for each Step.
(A5) Finish the logic simulation.
FIG. 6 shows the Steps when an error is found in Step M. Steps (B1) to (B6) in the following description correspond to Steps B1 to B6 of FIG. 6.
(B1) A program related to Step M (corresponding to a source file) is corrected, and the entire program after correction is recompiled.
(B2) The logic simulator is started and the logic simulation is started.
(B3) The object code of the corrected program is loaded down into ROM model 23.
(B4) General purpose CPU model 22 is started and the object codes are read out in sequence by ROM model 23, and instructions are executed.
(B5) The program of Steps 1 to M-1, already verified, is executed in sequence.
(B6) Step M in the corrected program is executed and verification is performed. If the errors have been removed as a result of verification, Step M will advance to the next Step M+1. On the other hand, if the errors still exist, Steps (B1) to (B5) will be repeated and executed.
However, in the procedure shown in FIG. 6, when an error is found in the verification in Step M, Step M is executed after the program for Step 1 to Step M-1, already verified has been executed in sequence. Thus, the time required to get to the verification of the error portion is additional so that verification of the error portion cannot be performed with efficiency. This reduces verification efficiency of the software of the CPU mounted circuit.
Category (c) Prior Art System and Problems
Efficiency of logic simulation and performance is an important consideration in the shortening of development time when developing hardware. Priorly, when verifying hardware by checking a signal wave form with logic simulation, a simulation display time width was set in advance to .delta.T, a signal waveform corresponding to time width .delta.T was displayed on the waveform window of a CRT screen, and this waveform was renewed and displayed every hour as the simulation proceeded, as shown in FIG. 7. That is .delta.T=TR-TL. It was usual that the simulation be stopped when the waveform shown in the waveform window arrived at a verification point, and the waveform held on the window is checked visually.
However, there are few cases where visual checking can be performed without changing the display time width .delta.T when checking is performed. That is, when the display time width .delta.T is too large, the waveform at the verification point is too small, as shown in FIG. 8, so that a fine signal change is difficult to observe. For this reason, the window of FIG. 8 is renewed to be a window in which a section between time T12 and T13 (such as that shown in FIG. 9) is displayed on an enlarged scale, checking is performed on the renewed window. On the other hand, if an enlarged display such as shown in FIG. 9 is displayed, the display time width .delta.T becomes too small, so that the entire signal change is often difficult to observe. In such a case, the section between time T12 and T13 of FIG. 9 is displayed on a reduced scale, and checking is performed on a window, such as that shown in FIG. 8.
Thus, depending on the circumstances, an enlarged display or reduced display, may be needed at the verification point. Thus, verification cannot be performed with a single fixed magnification of the display. Thus, in the prior art when an enlarged display or reduced display is needed at each verification point, simulation remains stopped during the time the enlargement or reduction is being produced. Accordingly, the time required for simulation is increased and efficiency is reduced.
Category (d) Prior Art System and Problems
Along the same lines of efficiency of logic simulation, when performing logic simulation, a plurality of waveforms of signal data, which are necessary for verification of a target circuit model, are displayed on a CRT window, such as shown in FIG. 10, for example. Logic simulation is stopped at the point where the verification of hardware is performed. At that point, the signal waveform is partially enlarged or reduced. Verification is performed by visually checking the enlarged or reduced waveform.
However, since logic simulation is stopped at each verification point and then the waveform is checked, logic simulation cannot be performed during the checking. Thus, also when verification of the target circuit mode is performed, the time required for logic simulation becomes longer and efficiency of logic simulation is reduced further.
Category (e) Prior Art System and Problems
In the verification support system, there are cases where two target logics are verified with use of a single system, and the waveforms obtained from the respective target logics are compared.
FIG. 11 shows a target logic comprising two target logics 1.sub.1 and 1.sub.2, each comprising general purpose CPU 2.sub.1, 2.sub.2 which become the cores of target logics 1.sub.1 and 1.sub.2 ; ROM 3.sub.1, 3.sub.2 for program storage; RAM 4.sub.1, 4.sub.2 for data storage; and user logic 5.sub.1, 5.sub.2 which are circuits built by the user. User logics 5.sub.1, 5.sub.2 are signal processing circuits including an A/D converter, and the like, for example, and can be used to access general purpose CPU 2.sub.1, 2.sub.2 for reading and writing data.
When verification of the hardware and software of the target logic shown in FIG. 11 is performed with logic simulation, a virtual model of a target logic is made, such as shown in FIG. 12.
FIG. 12 shows target logic models 21.sub.1, 21.sub.2 comprising general purpose CPU models 22.sub.1, 22.sub.2 ; ROM models 23.sub.1, 23.sub.2 ; RAM models 24.sub.1, 24.sub.2 ; and user logic models 25.sub.1, 25.sub.2. These are virtual models of the corresponding target logics 1.sub.1, 1.sub.2, and are realized by use of appropriate software. Logic simulation is performed on a target logic model, such as shown in FIG. 12, and verification of the hardware and software of the target logic model is performed.
A source file described in C language, for example, is compiled with a C compiler, and object codes comprising 0 and 1 patterns, generated as a result, are loaded down into ROM models 23.sub.1, 23.sub.2, when logic simulation is started. The loaded programs are executed by general purpose CPU models 22.sub.1, 22.sub.2, respectively. The source file is an application program made by the user, and the C compiler is provided by the user.
How efficiently the above logic simulation can be performed is an important consideration in the shortening of development time to develope the hardware. Priorly, when signal data, necessary for verification of the target logic model, were displayed on the waveform window of a CRT display unit, as the hardware was verified by checking the waveform with logic simulation, there were limitations on the number of waveform windows that can be displayed at the same time. Also, in the example of the target logic shown in FIG. 12, the signal data were divided into two groups to display waveforms so that they were easy to observe. That is, the signal data were grouped into signal data necessary for verification of target logic model 21.sub.1 and signal data necessary for verification of target logic model 21.sub.2. These two groups of data were respectively displayed on waveform windows #1 and #2, as shown in FIG. 13. In the windows of FIG. 13, CLK represents a clock to provide operating timing; XAS represents an address strobe signal of negative logic; HA represents a host address; and XRW represents a read/write signal of negative logic. "16'hffff" is data which is given as a default when the host address HA is not determined.
Each of the waveform windows #1 and #2 is provided with a PAUSE button and a RUN button, for example. The renewal of the waveforms in the windows is stopped temporarily by pushing the PAUSE button. The renewal of the waveforms in the window is restarted by pushing the RUN button. In such a conventional display window, the renewal of the waveform window can be stopped or restarted independently for each window.
However, when it is desired that the renewals of the two windows be stopped at the same time, the PAUSE button of window #1 must be pushed first, and then, the PAUSE button of window #2 is pushed. For this reason, when the two windows are stopped, there is a difference in simulation time between the waveforms of windows #1 and #2, as shown in FIG. 14. Thus, the waveforms must be checked and the difference in time between the two windows must be taken into account. Thus, the checking of the waveforms cannot be performed efficiently. In FIG. 14, the pushed PAUSE buttons have been changed from .quadrature. to .box-solid..
Also, when it is desired that the renewals of the two windows be restarted at the same time, likewise, the RUN button of window #1 must be pushed first and then the RUN button of window #2 is pushed. Thus, when the windows are restarted, there is difference in simulation time between the waveforms of window #1 and window #2, as shown in FIG. 15, so that the same problem exists as that of stopping.
Each time the stop and restart of the simulation is performed, the difference in time between the two windows is accumulated. Thus, checking of the waveforms cannot be done efficiently, and efficiency of logic simulation is reduced.
Category (f) Prior Art System and Problems
Verification of a sequence program executed by a PLC is discussed next. The PLC is one of representative controllers used in a sequence control system. FIG. 16 shows a sequence control system comprising input part 31, calculation control logic 32, output part 33, and operating window 34. External information is inputted to input part 31, for example, through a limit switch, a toggle switch, a relay switch, or as an analog input. Calculation control logic 32 comprises a memory 321 for storing a sequence program and information and a CPU 322 for executing the sequence program. Output part 33 outputs the results of calculation to the outside, for example, to a motor, a lamp, a solenoid, or as an analog output signal. Operating window 34 inputs a sequence program to calculation control logic 32.
Recently, customers have demanded that PLCs have process control processing function, information processing function, and data processing function, in addition to the original sequence control processing function. Accordingly, the PLC tends now to be large in scale and complex, so that the efficiency of design is increasingly desired. In particular, as the PLC becomes large in scale and more complex, generally a sequence program is also increased in the number of Steps used, and increased in complexity. Thus, improving the verification efficiency of the sequence program contributes to improvement in efficiency in designing of the entire PLC.
FIG. 17 shows the basic steps of a conventional design of a sequence program. In the following description Steps (C1) to (C8) correspond to Steps C1 to C8 of FIG. 17.
(C1) First, the specification of a system, which is the target of control, is examined.
(C2) Next, allocation of the number of input-output units to which an input-output device is connected, is determined.
(C3) Then, based on a timing diagram, and the like, the design of a sequence circuit is made, with a ladder diagram, for example, and the control steps are expressed definitively.
(C4) The allocation of an internal memory, a timer, a counter, and the like, is made at the same time as the sequence circuit is being designed, or after the design is completed.
(C5) When the sequence circuit is completed, a circuit entry is made with a programming tool, and the sequence circuit is converted into a mnemonic (i.e. mechanical word of PLC). As a method of circuit entry, one may use (a) the method of drawing the symbol of a ladder diagram on the CRT window; or (b) the method of directly coding command words such as AND or OR as logic symbols.
(C6) When the making of the sequence program is completed, debugging is performed on a disk with the programming tool.
(C7) The debugged program is stored in the memory of PLC.
(C8) The sequence program is debugged by trial of the program. If the sequence program is not operated correctly, it will be corrected or changed as needed.
However, in the conventional method in which after the hardware and software have been coupled to construct a real system, the sequence program is verified on a full scale by trial of the program, as described above. The following problems were found in such conventional methods.
(1) The verification of the sequence program was performed after an actual system was constructed, so that when it was necessary to correct or change the sequence program, the correction or change became troublesome and efficiency was reduced. More particularly, when the control of the PLC was extremely complex, correction or change tended to repeatedly occur until the verification of the sequence program was completed, so that verification takes a considerable amount of time.
(2) At the stage of examining the specification of a system, it was difficult to quantitatively estimate the allocation of control by hardware and control by software, together with the performance of the PLC. When the program is completed, and when program trial is just starting, if an objectional point is just found, a large change or correction of the sequence program cannot be avoided, and in some cases, the sequence program must be redesigned in entirety.